Safe interoperability among web services

ABSTRACT

The joining of Web services is accomplished via a virtual contract through the use of safeties. The joining of Web services heightens the safe interoperability of Web services to create greater functionality than each Web service alone can provide. Moreover, because the joining of Web services is formed programmatically, Web services are more trustworthy, dependable, and available if the safeties of Web services are complied with. The programmatic joining reduces or eliminates mistakes, lost requests, faults in the face of invalid requests, or corrupt persisted data in the interoperability of Web services

FIELD OF THE INVENTION

[0001] The present invention relates generally to Web services, and moreparticularly, to interoperability among Web services.

BACKGROUND OF THE INVENTION

[0002] Web services are the fundamental building blocks in the movementtoward distributed computing on the Internet. Open standards and thefocus on communication and collaboration among software applicationshave created an environment where Web services are becoming the platformof choice for application integration. Applications are constructedusing multiple Web services from various sources that work togetherregardless of where they reside or how they are implemented. Webservices represent black-box functionality that can be used or reusedwithout the need to know the inner working of Web services. One of theprimary advantages of Web services' architecture is that thearchitecture allows Web services written in different languages ondifferent platforms to communicate with each other with ease viamessages. Moreover, a significant number of corporations and companiesalready have a Web infrastructure and personnel with deep knowledge andexperience in maintaining such an infrastructure, thereby allowing morefluid adoption of Web services as a platform for future applications.

[0003] Examples of Web services include information sources that onecould easily incorporate into applications, such as stock quotes,weather forecasts, sports scores, etc. Beyond information sources, onecan imagine a whole class of applications that can be built from Webservices to analyze and aggregate information desired by interestedpersons, and present the information to the interested persons. Forexample, consider a spreadsheet that summarizes a person's wholefinancial picture: stocks, 401K, bank accounts, loans, etc. If thisinformation were available through Web services, a spreadsheetapplication could update the information continuously. While most piecesof information may be available now on the Web in a mixture ofincongruous, haphazard elements, Web services make programmatic accessto all pieces of information easier and more reliable.

[0004] Web services are diverse, but almost all of them have threethings in common: (1) Web services expose useful functionality to usersvia a set of interfaces through a standard protocol, such as SimpleObject Access Protocol (SOAP); (2) Web services describe the set ofinterfaces in a document called a contract using Web ServicesDescription Language (WSDL), which is written in enough detail to allowusers to build client applications to talk to Web services; and (3) Webservices are registered so that potential users can find Web serviceseasily using Universal Discovery Description and Integration (UDDI). Inother words, a Web service is a piece of software exposed on the Webthrough a particular protocol, described with a particular WSDLcontract, and registered in a parcticular location in the UDDI.

[0005] As discussed above, a WSDL contract describes interfaces of Webservices in enough detail to allow a user to build a client application.More particularly, a WSDL contract is a document that describes a set ofmessages written in a particular protocol and how these messages are tobe exchanged. In other words, a WSDL contract describes a Web serviceinterface in terms of messages the Web service can generate and accept.WSDL contracts are readable and editable, but in most cases, WSDLcontracts are intended to be produced and consumed by software.

[0006] To see the value of WSDL contracts, consider a user who desiresto call a method in a Web service that is provided by one of the user'sbusiness partners. The user can obtain from the business partner somesample messages generated and accepted by the method. Then the user canproceed to write an application to produce and consume messages thatlook like the given sample messages. This technique is fraught witherrors, however. For example, the user might see a customeridentification “2837” in a message and assume that the identification isan integer when, in fact, it is a string. WSDL contracts specify what arequest message must contain and what the response message will looklike in an unambiguous notation.

[0007] The notation that WSDL contracts use to describe message formatsis based on the XML Schema standard, which is not dependent on anyparticular programming language, and is suitable for describing Webservices interfaces that can be accessible from a wide variety ofplatforms and programming languages. In addition to describing messagecontent, WSDL contracts define where the service is available and whatcommunications protocol can be used to talk to the service. Thus, a WSDLcontract should define everything that is required to write anapplication to work with a Web service.

[0008] Unfortunately, WSDL contracts lack the expressive power to defineprecisely how an application is to interact with a Web service. Althoughthe term “contract” means a binding agreement between two softwareentities, an application that is interacting with a Web service is freeto ignore the terms of a WSDL contract. Thus, a WSDL contract appears asnothing more than a paper tiger. A system 100 shown in FIG. 1illustrates this problem in greater detail.

[0009] The system 100 includes a client 102, which is a computer thataccesses shared network resources being provided by another computer,such as a server 106, on a local area network or wide area network suchas the Internet 104. A number of Web services 108, 110, are staticallystored on the client 102 and the server 106. Web services 108, 110 arecomposed of programs 108A, 110A, and WSDL contracts 108B-110B.

[0010] Each WSDL contract can be divided into two major sections. Thefirst section contains abstract definitions and the second sectioncontains concrete descriptions. The abstract definitions definecontractual elements in a platform-independent and language-independentmanner. The abstract definitions do not contain machine-specific orlanguage-specific elements. This helps define a set of services thatseveral diverse Web sites can implement. Site-specific elements, such asdata serialization, are relegated to the concrete descriptions. Abstractdefinitions include definitions for types, messages, and porttypes. theconcrete descriptions specify bindings and services. The types sectiondeclares data types used in a WSDL contract. The messages sectiondefines parameters to operations (i.e., methods). The porttypes sectiondefines one or more operations that can be invoked by applications (andother Web services) external to a Web service described by a WSDLcontract. The bindings section can have one or more binding elementswhose purpose is to specify how each call and response to an operationis sent or received over the network 104 in accordance with a protocol.The services section has one or more service elements, each of whichcontains port elements, and each of which in turn refers to a bindingelement in the bindings section.

[0011] Structure 112 illustrates the relationship among contractualelements of the contract 108B and is shown in block diagram form. Aporttype 112D declares a number of operation elements. Operationelements within a porttype define the syntax for calling all methodsdeclared in a porttype, such as a prepare operation 112E, a “do work”operation 112F, and a “clean up” operation 112G. Thus, each operationelement in a porttype defines the name of the method, the parameters(using messages), and the type of each parameter. There can be severalporttypes within a WSDL contract. Each porttype groups together a numberof related operations.

[0012] A binding element 112C specifies the protocol, serialization, andencoding to be used for each operation 112E-112G of the porttype 112D. Aport element 112B associates an Internet location with the binding 112Cin a one-to-one correspondence via the use of a Uniform Resource Locator(URL). A service element 112A contains a set of port elements, such asthe port 112B. There can be more than one service element in a WSDLcontract. Each service element can be used to group together portsaccording to a URL destination. For example, a developer can redirectall service requests simply by using another service element, andexternal Web services can still interact with a Web service. Another useof the service element is to classify the ports according to anunderlying protocol. For example, a developer can put all HTTP ports inone service element and all SMTP ports in another. An external Webservice can then search the WSDL contract 108B for the service thatmatches the protocol that it can deal with.

[0013] As indicated above, the WSDL contract 108B includes severaloperations, such as the “prepare” operation 112E, the “do work”operation 112F, and the “clean up” operation 112G, which can be invokedto access the services provided by the Web service 108. However, the“prepare” operation 112E should be invoked before the “do work”operation 112F, and the “do work” operation 112F should be invokedbefore the invocation of the “clean up” operation 112G. Prior WSDLcontracts lack the expressiveness power to communicate this orderinginformation to other Web services, such as the Web service 110, that maydesire the services of the Web service 108. For example, the Web service110 may choose to initially call the “clean up” operation 112G insteadof first invoking the prepare operation 112E. This could be catastrophicto the working of the Web service 108 in that it may corrupt theinternal execution state of the Web service 108. Moreover, suppose thatthe Web service 110 is malicious. In this case, the Web service 110 canexploit this weakness of the Web service 108 by calling operations112E-112G out of sequence simply to wreak havoc with the properoperation of the Web service 108. If Web services can be inappropriatelyexploited in this fashion, trustworthiness of Web services will bequestioned and their use will be diminished and eventually extinguishedfrom the marketplace.

[0014] Thus, there is a need for better methods and systems for allowingWeb services to safely interact with other Web services while avoidingor reducing the foregoing and other problems associated with existingWeb services.

SUMMARY OF THE INVENTION

[0015] In accordance with this invention, a system, method, andcomputer-readable medium for improving the safe interoperability of Webservices is provided. The system form of the invention comprises a firstWeb service for offering computing services and a second Web servicethat desires the computing services offered by the first Web service.The first Web service includes a first port for transmitting andreceiving messages and the second Web service includes a second port fortransmitting and receiving messages. The first port includes a firstporttype and the second port includes a second porttype. The second portis fusable with the first port for safe access to the services offeredby the first Web service if the second porttype is compatible with thefirst porttype.

[0016] In accordance with further aspects of this invention, a furthersystem form of the invention comprises a first Web service offering afirst set of services and a second Web service offering a second set ofservices. The first Web service includes a first safety (thatprogrammatically expresses safe access to the first set of services) anda second Web service includes a second safety (that programmaticallyexpresses safe access to the second set of services). The second Webservice accesses the first set of services and the first Web serviceaccesses the second set of services if the second safety is able toprogrammatically align with the first safety.

[0017] In accordance with further aspects of this invention, anothersystem form of the invention comprises a first Web service offeringservices. The first Web service includes a safety that programmaticallydescribes an order in which to access the offered services. The systemfurther comprises a second Web service that desires to use the servicesoffered by the first Web service. The second Web service accepts thesafety of the first Web service to form a virtual contract with thefirst Web service so that the second Web service can access the offeredservices.

[0018] In accordance with further aspects of this invention, acomputer-readable form of the invention stores a customizable, tag-baseddata structure suitable for use by a Web service to evaluate safeinteroperability with another Web service. More particularly, the datastructure comprises a porttype tag that is indicative of operationscapable of being invoked by Web services and a safety tag that isindicative of a safety that programmatically specifies an order by whichWeb services invoke the operations.

[0019] In accordance with further aspects of this invention, the methodform of the invention is implementable in a computer system. The methodcomprises creating a set of operations that are capable of being invokedby Web services and creating a safety that specifies the permissibleinvocation permutations of the set of operations.

[0020] In accordance with further aspects of this invention, anothermethod form of the invention is a computer-implementable method forchecking the compatibility of a first porttype of a first Web serviceand a second porttype of the second Web service. The method comprisesextracting a first safety from the first porttype of the first Webservice and a second safety from the second porttype of the second Webservice. The method further comprises testing the compatibility of thefirst safety with the second safety by binding the first safety with thesecond safety to determine whether the result of the binding is aninput-guarded process.

BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The foregoing aspects and many of the attendant advantages ofthis invention will become more readily appreciated as the same becomebetter understood by reference to the following detailed description,when taken in conjunction with the accompanying drawings, wherein:

[0022]FIG. 1 is a block diagram illustrating a conventional Web servicessystem;

[0023]FIG. 2 is a block diagram illustrating an exemplary computingdevice;

[0024] FIGS. 3A-3C are block diagrams illustrating the creation of aspecification for a Web service that contains safeties to define theorder in which operations of a Web service are to be invoked;

[0025]FIG. 4 is a textual diagram illustrating syntaxes of an exemplaryprogramming language, which is an artificial language that can be usedto define a sequence of instructions that can ultimately be processedand executed for expressing safeties used in interoperability agreementsamong Web services;

[0026] FIGS. 5A-5C are block diagrams illustrating the safeinteroperability of two Web services when their ports have been fusedpursuant to the formation of a virtual contract between the two Webservices;

[0027] FIGS. 6A-6I are diagrams illustrating the creation of a virtualcontract for safe interoperability among three Web services, each Webservice providing a service or resource to another Web service in thevirtual contract;

[0028] FIGS. 7A-7B are diagrams illustrating syntaxes of anotherexemplary programming language for forming safeties used ininteroperability agreements among Web services; and

[0029] FIGS. 8A-8O are method diagrams illustrating an exemplary methodformed in accordance with this invention for verifying the compatibilityof porttypes among Web services so as to form safe interoperabilityamong Web services.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

[0030]FIG. 2 illustrates an example of a computing system environment200 suitable for practicing certain aspects of the invention, such asexecuting programs of Web services and verifying the specifications ofWeb services for safe interoperability. The computing system environment200 is only one example of a suitable computing environment and is notintended to suggest any limitation as to the scope of use orfunctionality of the invention. Neither should the computing environment200 be interpreted as having any dependency or requirement relating toany one or combination of the illustrated and described components.

[0031] The invention is operational with numerous other general purposeor special purpose computing system environments or configurations.Examples of well-known computing systems, environments and/orconfigurations that may be suitable for use with the invention include,but are not limited to, personal computers, server computers, hand-heldor laptop devices, multiprocessor systems, microprocessor-based systems,set top boxes, programmable consumer electronics, network PCs,minicomputers, mainframe computers, distributed computing environmentsthat include any of the above systems or devices, and the like.

[0032] The invention is described in the general context ofcomputer-executable instructions, such as program modules being executedby a computer. Generally, program modules include routines, programs,objects, components, data structures, etc. that perform particular tasksor implement particular abstract data types.

[0033] The invention may also be practiced in distributed computingenvironments where tasks are performed by remote processing devices thatare linked through a communications network. In a distributed computingenvironment, program modules may be located in both local and remotecomputer storage media, including memory storage devices.

[0034] The computing system environment illustrated in FIG. 2 includes ageneral purpose computing device in the form of a computer 210.Components of computer 210 may include, but are not limited to, aprocessing unit 220, a system memory 230, and a system bus 221 thatcouples various system components including the system memory to theprocessing unit 220. The system bus 221 may be any of several types ofbus structures, including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such busarchitectures include Industry Standard Architecture (ISA) bus, MicroChannel Architecture (MCA) bus, Enhanced ISA (EISA) bus, VideoElectronics Standards Association (VESA) local bus, and PeripheralComponent Interconnect (PCI) bus, also known as Mezzanine bus.

[0035] Computer 210 typically includes a variety of computer-readablemedia. Computer-readable media can be any available media that can beaccessed by computer 210 and includes both volatile and nonvolatilemedia, removable and non-removable media. By way of example, and notlimitation, computer-readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information, such ascomputer-readable instructions, data structures, program modules, orother data. Computer storage media include, but is not limited to, RAM,ROM, EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tapes, magnetic disk storage or other magnetic storage devices,or any other computer storage media. Communication media typicallyembody computer-readable instructions, data structures, program modulesor other data in a modulated data signal, such as a carrier wave orother transport mechanism that includes any information delivery media.The term “modulated data signal” means a signal that has one or more ofits characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media include wired media, such as a wired network ordirect-wired connection, and wireless media, such as acoustic, RFinfrared, and other wireless media. A combination of any of the aboveshould also be included within the scope of computer-readable media.

[0036] The system memory 230 includes computer storage media in the formof volatile and/or nonvolatile memory, such as read only memory (ROM)231 and random access memory (RAM) 232. A basic input/output system 233(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 210, such as during start-up, istypically stored in ROM 231. RAM 232 typically contains data and/orprogram modules that are immediately accessible and/or presently beingoperated on by processing unit 220. By way of example, and notlimitation, FIG. 2 illustrates operating system 234, applicationprograms 235, other program modules 236, and program data 237.

[0037] The computer 210 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 2 illustrates the hard disk drive 241 that reads from or writes tonon-removable, nonvolatile magnetic media, the magnetic disk drive 251that reads from or writes to a removable, nonvolatile magnetic disk 252,and an optical disk drive 255 that reads from or writes to a removable,nonvolatile optical disk 256, such as a CD-ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital videotapes, solid state RAM, solidstate ROM, and the like. The hard disk drive 241 is typically connectedto the system bus 221 through a non-removable memory interface, such asinterface 240, and the magnetic disk drive 251 and optical disk drive255 are typically connected to the system bus 221 by a removable memoryinterface, such as interface 250.

[0038] The drives and their associated computer storage media discussedabove and illustrated in FIG. 2 provide storage of computer-readableinstructions, data structures, program modules and other data for thecomputer 210. In FIG. 2, for example, hard disk drive 241 is illustratedas storing operating system 244, application programs 245, other programmodules 246, and program data 247. Note that these components can eitherbe the same as or different from operating system 234, applicationprograms 235, other program modules 236, and program data 237. Operatingsystem 244, application programs 245, other program modules 246, andprogram data 247 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 210 through input devices, such as akeyboard 262 and pointing device 261, the latter of which is commonlyreferred to as a mouse, trackball, or touch pad. Other input devices(not shown) may include a microphone, joystick, game pad, satellitedish, scanner, or the like. These and other input devices are oftenconnected to the processing unit 220 through a user input interface 260that is coupled to the system bus, but may be connected by otherinterface and bus structures, such as a parallel port, game port, oruniversal serial bus (USB). A monitor 291 or other type of displaydevice is also connected to the system bus 221 via an interface, such asa video interface 290. In addition to the monitor, computers may alsoinclude other peripheral output devices, such as speakers 297 andprinter 296, which may be connected through an input/output peripheralinterface 295.

[0039] The computer 210 may operate in a networked environment usinglogical connections to one or more remote computers, such as a remotecomputer 280. The remote computer 280 may be a personal computer, aserver, a router, a network PC, a peer device, or other common networknode, and typically includes many or all of the elements described aboverelative to the computer 210, although only a memory storage device 281has been illustrated in FIG. 2. The logical connections depicted in FIG.2 include a local area network (LAN) 271 and a wide area network (WAN)273, but may also include other networks. Such network environments arecommonplace in offices, enterprise-wide computer networks, intranets,and the Internet.

[0040] When used in a LAN networking environment, the computer 210 isconnected to the LAN 271 through a network interface or adapter 270.When used in a WAN networking environment, the computer 210 typicallyincludes a modem 272 or other means for establishing communications overthe WAN 273, such as the Internet. The modem 272, which may be internalor external, may be connected to the system bus 221 via the input/outputperipheral interface 295, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 210, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 2 illustrates remoteapplication programs 285 as residing on memory device 281. It will beappreciated that the network connections shown are for illustrativepurposes only and other means of establishing a communication linkbetween the computers may be used.

[0041]FIG. 3B illustrates a Web service 300 that includes a program300A, which is a sequence of instructions of the Web service 300 thatcan be executed by a computing device, and a specification 300B (shownas “spec” in the drawings), which is a description of the interfaces ofthe Web service 300. The specification 300B, unlike a WSDL contract,contains safety rules (hereinafter “safeties”) that describe an order inwhich external Web services can invoke the operations of the Web service300. In other words, each safety describes the allowable or permissibleinvocation permutations of the operations of the Web service 300 withwhich external Web services can call to access the services offered bythe Web service 300. If these safeties are not acceptable to an externalWeb service who is desirous of using the services of the Web service300, no virtual contract will be formed. Otherwise, if the safeties areacceptable to the external Web service, a virtual contract will beformed, and safe interoperability between the external Web service andthe Web service 300 is possible.

[0042] A block diagram that illustrates the structure 302 of the Webservice 300 is shown in FIG. 3A. A service element 302A taxonomicallydifferentiates other services described by the specification 300B bygrouping together a set of ports (not shown). Each port is associatedwith a porttype. The structure 302 has a porttype 302B. The porttype302B declares a number of operations, such as a prepare operation 302D,a dowork operation 302E, and a cleanup operation 302F. For claritypurposes, the following terms are used as follows in the discussionbelow: the term “operation” is used interchangeably with the term“message” (in contrast, the term “message” in a WSDL contract means onlyan argument to an operation); the term “parameter” is used to denote anargument to an operation; and the term “binding” is used to mean aprogrammatic relationship between two safeties, which are explainedbelow (in contrast, the term “binding” in a WSDL contract means anassociation of a porttype with a particular transfer protocol).

[0043] The order in which operations 302D-302F are to be invoked isspecified by safeties 302C which have the following forms: (1)S=prepare.SW; and (2) SW=(dowork).SW+(cleanup). The safeties 302C aretextually expressed by a portion 304 of the specification 300B. See FIG.3C. Line 304A contains the keyword porttype, which declares thecommencement of a definition for a porttype; a designator“start_work_stop”, which is the name of the porttype; and an open curlybracket “{”, which has a matching closed curly bracket “}” to delimit ablock of text that programmatically defines the porttype. Line 304Bdeclares the prepare operation 302D, which takes a string as aparameter. Line 304C declares a dowork operation 302E as well as itsparameter, a string. Line 304C declares a cleanup operation 302F thathas a string parameter.

[0044] These operations declared on lines 304B-304D are the operationsavailable to an external Web service for it to access the services ofthe Web service 300. For some Web services, operations should be invokedin a particular order for proper interoperability with these Webservices. For example, in the Web service 300, the prepare operation302D should be called before the dowork operation 302E, and the doworkoperation 302E should be called before the invocation of the cleanupoperation 302F. To allow this ordering information to be conveyed, oneor more safeties can be formed in accordance with this invention. Seelines 304E, 304F. Permutational nuances of a safety can be expressedusing the human-readable syntax 400 shown in FIG. 4 (described below);the model syntax 702 shown in FIG. 7A (described below); or the transfersyntax discussed in Appendix B.

[0045] The safeties on lines 304E, 304F is expressed as two sentences:(1) S=prepare.SW; and (2) SW=(dowork).SW+(cleanup). The letter S is thename of the first safety and the letter SW is the name of the secondsafety. Each equal sign “=” indicates that the safety is equated to arule on the right-hand side of the equal sign “=”. Preceding the period“.” of the safety S is the prepare operation 302D indicating that theprepare operation 302D is to be invoked first after which the safety SWis in force. The period “.” after the dowork operation 302E but beforethe safety SW indicates that the dowork operation 302E is invoked afterwhich a recursion of the safety SW can occur. In other words, the phrase“.SW” following the dowork operation 302E indicates that zero or moreinvocations of the dowork operation 302E may be possible. The plus sign“+” indicates that either the dowork operation 302E or the cleanupoperation 302F may be invoked following the invocation of the prepareoperation 302D. The cleanup operation 302F placed last in the sentenceof the safety SW indicates that the cleanup operation 302F should becalled last or invoked by an external Web service using the services ofthe Web service 300. Each semicolon “;” following safeties S and SWindicates the termination of the sentence of the safeties on lines 304E,304F.

[0046] Porttypes and safeties can be expressed using the human-readablesyntax 400 illustrated in FIG. 4 (after which they can be preferablyplaced in a specification of a Web service, such as the specification300B). Line 400A contains a definition for a port: porttype designator{signature; safety;}, where porttype is a keyword declaring thecommencement of the definition of a porttype; designator is anidentifier of the porttype; the pair of open and closed curly bracketsdelimit expressions that define the porttype; and safety indicates rulesthat define the order in which to invoke the operations described by thesignatures. Each signature has the syntactical expression “designator([designator:lineartype,designator:lineartype])” shown on line 400B,where the first designator is the identifier of a particular operation;the second and third designators bound by the, pair of parenthesesindicate identifiers of parameters of the operation; and the two lineartypes define the data type of each parameter (for brevity purposes, onlytwo parameter slots are defined for the signature on line 400B, but morethan two are possible); the colon “:” indicates that the designator of aparameter on the left-hand side of the colon has the data type declaredon the right-hand side of the colon; the comma “,” delimits oneparameter from another parameter; and the pair of parentheses “( )”delimit the parameters and their types used by the operation.

[0047] Lines 400C-4001 define various types of safeties. A stop safetyis declared on line 400C. A stop safety denotes inactivity ortermination of a safety. A sequence safety declared on line 400D definesan order in which to invoke an operation or a message of a Web service.A choice safety and a menu safety declared on lines 400F, 400G denotealternatives that can be chosen in a safety. On line 400G, a parallelsafety is defined to denote concurrent, distributed processing of twosafeties. A recursion safety, which defines a variable whose use isrecursive in a safety, is declared on line 400H. A reference safetydeclared on line 400I denotes that a safety can be given a name to beused in combination with other safeties. Line 400J shows that the stopsafety is composed of the symbol zero “0”. The sequence safety iscomposed of a signature of a function followed by a period “.”, which isthen followed by another safety. See line 400K. Whereas the choicesafety is composed of two safeties separated by a plus sign “+” (seeline 400L), the menu safety is composed of two safeties separated by anampersand sign “&” (see line 400M). The parallel safety defined on line400N is composed of two safeties separated by a vertical sign “I”. Therecursion safety is composed of a keyword “rec” followed by a pair ofparentheses, which bound a designator, and is followed by a period andanother safety rule. See line 400O. Using the recursion safety, safeties(S=prepare.SW; SW=(dowork).SW+(cleanup)) can be equivalently written asa safety (prepare.rec(SW).((dowork).SW+(cleanup))). Line 400P indicatesthat a reference safety is simply a designator, which is a name or anidentifier.

[0048] Using the human-readable syntax 400, expressive nuances ofsafeties can be specified to enhance safe interoperability among Webservices. Each safety is preferably placed in a porttype definition in aWeb service's specification. The human-readable syntax 400 isillustrated here for ease of discussion in figures following FIG. 4. Amore restrained, but equally expressive is the model syntax 702illustrated in FIG. 7A (described below). Similar subtle variations ofsafeties can also be expressed using the transfer syntax described inAppendix B. The transfer syntax is formed using a suitable customizable,tag-based language. Any suitable customizable, tag-based language can beused. One suitable language includes the XML Schema language. Thetransfer syntax is preferably used to fit safeties formed in accordancewith this invention into existing porttype definitions of WSDLcontracts.

[0049] A fileserver Web service 502 is shown at FIG. 5A in block diagramform. The fileserver Web service provides file storage services forother Web services on the network. Unlike a disk server, the filerserverWeb service 502 not only stores files but manages them and maintainsorder as other Web services request files and make changes to them. Todeal with the tasks of handling multiple (sometimes simultaneous)requests for files, the Web service 502 interacts with processors andcontrolling software as well as disk drives for storage.

[0050] The fileserver Web service 502 includes a service element 502A,and a porttype 502B, among other elements (not shown). The porttype 502Bdefines a number of operations, such as an open operation 502D, a readoperation 502E, a write operation 502F, and a close operation 502G.These operations 502D-502G are further defined in a portion 504 of afileserver Web service's specification. See FIG. 5B. The porttype 502Balso defines safeties 502C, which specify the order with which externalWeb services access the services offered by the fileserver Web service502D via operations 502D-502G. The safeties 502C are further defined inthe portion 504. See lines 504F, 504G. A port 502H of the fileserver Webservice 502 allows other Web services to fuse (described in detailbelow) in order to access the services of the fileserver Web service502B by invoking operations 502D-502G.

[0051] The portion 504 focuses on one porttype definition among manyporttypes of the fileserver Web service's specification. Line 504Acontains the keyword porttype followed by the designator “fileserver”,and a pair of open and closed curly brackets for delimiting thedefinition of the fileserver porttype 502B. Line 504B declares thesignature of the open operation 502D that takes a file name as aparameter. In all cases, to use the services of the fileserver Webservice 502, external services specify the name of the file to be openedvia the open operation 502D. Thus, the open operation 502D should be thefirst operation that is invoked by external Web services for eachparticular file server session. The read operation 502E is declared online 504C. The read operation takes a client's port as a parameter. Whenthe read operation 502E is invoked by external Web services, thefileserver Web service 502 reads a chunk of data from an opened file,and transmits the read data toward the given client's port. External Webservices can also write information to opened files via the writeoperation 502F, which is declared on line 504D. The write operationtakes data as a parameter. This data is written by the write operationto the opened file. When all desired operations have been carried out onthe opened file, the opened file can be closed via the close operation502G, which is declared on line 504E. The close operation 502G takes afile name as an argument so that the close operation 502G knows whichfile to close.

[0052] Lines 504F-504G contain the safeties of the fileserver porttype502B. Line 504F contains a safety sentence: S=open.Srw, where S is asafety rule; open denotes that the open operation 502D is the firstoperation to be invoked in a file server session; the period “.” denotesthat additional safeties are to follow the invocation of the openoperation 502D; Srw refers to a second safety defined further on line504G. Line 504G contains the following safety sentence: Srwread.Srw&write.Srw&close, where Srw denotes the second safety; read.Srwdenotes the invocation of the read operation 502E, which is thenfollowed by the second safety again (a recursion); write.Srw denotes theinvocation of the write operation 502F, which is then followedrecursively by the second safety; close denotes the invocation of theclose operation 502G; and the ampersands “&” denote choices thatexternal Web services can make to invoke among the read operation 502E,the write operation 502F, or the close operation 502G.

[0053] A system 500 shows the interoperability of Web services 502, 508after a virtual contract has been created. See FIG. 5C. A virtualcontract is created when the porttypes of ports 502H, 508A between theWeb services 502, 508 are compatible. More particularly, a virtualcontract is created when the safeties of the porttypes of ports 502H,508A are acceptable to both the Web services 502, 508. A virtualcontract is not something that physically exists but it is present whenthe safeties of porttypes align with each other in a way that ensuressafe interoperability between Web services 502, 508. For claritypurposes, many elements of the fileserver Web service 502 are not shownin FIG. 5C. The fileserver Web service 502 can be executed on acomputing device, such as a cellular phone 506; the client Web service508 can be executed on a computing device, such as a personal digitalassistant 510; and a store Web service 512 can be executed on acomputing device, such as a desktop computer 514.

[0054] The port 508A of the client Web service 508 is shown to be fusedto the port 502H of the fileserver Web service 502. This fusing betweenthe client Web service 508 and the fileserver Web service 502 ispossible after the client Web service 508 has shown that it is willingto comply with the safeties of the fileserver porttype 502B. With thefusing of ports 508A-502H, the client Web service 508 can access andinvoke operations 502D-502G of the fileserver Web service 502 inaccordance with and in the manner specified by the safeties of thefileserver porttype.

[0055] Suppose that the client Web service 508 has already invoked theopen operation 502D to open a file. The client Web service 508 caninvoke the read operation 502E to obtain the read data. In theinvocation of the read operation 502E, the client Web service 508provides a port 508B to receive the read data after the invocation ofthe read operation 502E. The fileserver Web service 502 includes a port502I for transmitting the read data toward the port 508B. It is notnecessary, however, that the port 508B be an actual port at the clientWeb service 508. The port 508B can be virtually provided by another Webservice, such as the store Web service 512. A virtual contract may havebeen formed between the client Web service 508 and the store Web service512 to store information in a particular manner desired by the clientWeb service 508. Instead of providing the port 508B as a parameter tothe read operation 502E, the client Web service can provide the port512A of the store Web service 512 so that the data read by the readoperation 502E will be automatically forwarded to the store Web service512. This can occur unbeknownst to the fileserver Web service 502. Eachport is thus a transferable quantity that can be given to a Web serviceto expand the communication possibilities of a Web service. In thisexample, the prior scope of the fileserver Web service 502 is limited tothe interaction with the client Web service 508 but can later beexpanded to include the store Web service 512 when the port 512A istransferred to the fileserver Web service 502 via the client Web service508.

[0056] The joining of Web services, such as the fileserver Web service502 to the store Web service 512, is accomplished via a virtual contractthrough the use of safeties formed in accordance with this invention.This joining of Web services heightens the safe interoperability of Webservices to create greater functionality than each Web service alone canprovide. Moreover, because the joining of Web services is formedprogrammatically, Web services are more trustworthy, dependable, andavailable if the safeties of Web services are complied with. Theprogrammatic joining formed in accordance with this invention reduces oreliminates mistakes, lost requests, faults in the face of invalidrequests, or corrupt persisted data in the interoperability of Webservices.

[0057] The discussion above in connection with FIGS. 3A-3C introducesthe notion of safeties to a specification of a Web service. Because aporttype contains declarations of operations that external Web servicescan invoke to access services offered by a desired Web service, safetiesare preferably placed inside a porttype. As also discussed above,safeties describe the order with which external Web services must invokethe operations of a desired Web service to obtain desired services. Ifan external Web service cannot comply with the safeties of another Webservice at the outset, there is no binding agreement (a virtualcontract) between the two Web services, and the noncomplying Web servicecannot invoke the services of the other Web service. One example of acreation of a virtual contract between two Web services is discussedabove in connection with FIGS. 5A-5C. Because the client Web service 508is willing to comply with the safeties of the file server Web service502, the port 508A of the client Web service 508 can be fused to theport 502H of the file server Web service 502. Such a fusing allows theclient Web service 508 to invoke the services of the file server Webservice 502 at the port 502H. More particularly, a virtual contract canbe created when the porttype of the port 508A of the client Web service508 is programmatically compatible (or complies with the safeties of)the porttype of the port 502H of the file server Web service 502.Instead of forming a virtual contract between two Web services, thediscussion in connection with FIGS. 6A-6I focuses on a binding agreementamong three Web services (a purchaser Web service 602, a supplier Webservice 606, and a shipper Web service 610) formed in accordance withthis invention. However, virtual contracts can be formed without regardto the number of participating Web services as long as each Web serviceis willing to comply with the safeties of other participating Webservices.

[0058] The purchaser Web service 602 includes a service element 602A anda porttype element 602B, among other elements (not shown). The porttype602B includes an initiatepurchase operation 602D, a confirmpurchaseoperation 602E, and a safety 602C that specifies the invocation ofoperations 602D-602E. The purchaser Web service 602 also includes a port602F whose data type is the porttype 602B. See FIG. 6A. A portion 604 ofthe purchaser Web service's specification is illustrated in FIG. 6B.Line 604A contains the keyword porttype; the designator “purchaser” ofthe porttype; and an open curly bracket “{”, which has a companionclosed curly bracket to delimit the definition of the purchaser porttype602B. Line 604B contains a signature for the initiatepurchase operation602D, which has two parameters. One parameter is a purchase orderparameter designated as “PO”. The other parameter is an advancedshipping notice “˜ASN”, where the tilde “˜” denotes that the purchaserWeb service 602 consumes the data represented by the parameter ASN. Line604C contains a signature of the confirmpurchase operation 602E, whichtakes an “invoice” parameter and a “goods” parameter. The invoiceparameter is qualified by a tilde “˜” to denote that the purchaser Webservice 602 consumes the data represented by the invoice parameter. Boththe PO parameter and the goods parameter are not qualified by the tilde,hence indicating that the purchaser Web service 602 is the producer orthe source of the data represented by these parameters. Line 604Dcontains a safety for the purchaser porttype 602B. In brief, theinvocation of the initiatepurchase operation 602D must occur before theinvocation of the confirmpurchase operation 602E, which is then followedby a recursion of the invocation of operations 602D, 602E.

[0059] The supplier Web service 606 is illustrated in block diagram formin FIG. 6C. The supplier Web service 606 includes a service element 606Aand a porttype element 606B, among other elements (not shown). Theporttype 606B is a data type for a port 606F of the supplier Web service606. The porttype 606B contains a receivepo operation 606D, asendinvoice operation 606E, and a safety 606C that specifies theinvocation order of operations 606D, 606E. The supplier Web service 606also includes a port 606F whose data type is the porttype 606B. Aportion 608 of the supplier Web service's specification is shown in FIG.6D. Line 608A contains the declaration of a supplier porttype 606B andincludes an open curly bracket “{”, which has a companion closed curlybracket to delimit the definition of the supplier porttype 606B. Line608B contains a signature of the receivepo operation, which takes thepurchase order “˜PO” as a parameter. The tilde indicates that thesupplier Web service 606 consumes the data represented by the purchaseorder ˜PO parameter. Line 608C contains a signature of the sendinvoiceoperation 606E, which takes the invoice as a parameter. Line 608Dcontains a safety for the supplier porttype 606B. In brief, thereceivepo operation 606D is to be invoked prior to the invocation of thesendinvoice operation 606E, which can then be followed by the recursionof the invocation of operations 606D, 606E.

[0060] As shown in FIG. 6E, the shipper Web service 610 includes aservice element 610A and a porttype element 610B, among other elements(not shown). The porttype 610B describes the data type of a port 610F ofthe shipper Web service 610. The porttype 610B includes anotifyofshipment operation 610D, a confirmreceipt operation 610E, and asafety 610C, which specifies the invocation order of operations 610D,610E. A portion 612 of the shipper Web service's specification isillustrated in textual form in FIG. 6F. Line 612A contains thedeclaration of the shipper porttype 610B and an open curly bracket “{”,which has a companion closed curly bracket “}” to delimit the definitionof the shipper porttype 610B. Line 612B contains a signature of thenotifyofshipment operation 610D, which takes the advance shipping notice“ASN” as a parameter. Because the advanced shipping notice ASN is notqualified by a tilde, the shipper Web service 610 is a producer or asource of the data represented by the ASN parameter. Line 612C containsa signature of the confirmreceipt operation 610E, which takes “˜goods”as an argument. The tilde in front of the designator “goods” denotesthat the shipper Web service 610 is a consumer of the data representedby the “goods” parameter. Line 612D contains a safety for the shipperporttype 610B. In brief, the invocation of the notifyofshipmentoperation 610D occurs before the invocation of the confirmereceiptoperation 610E, and after which, a recursion of the invocation of theoperations 610E, 610E may occur.

[0061] A portion 614 of a program for expressing the composition of thepurchaser Web service 602, the supplier Web service 606, and the shipperWeb services 610 is shown in FIG. 6G. Line 614A contains a signature ofa purchaser Web service 602, which has a port designated as “PC” havingthe purchaser porttype 602B. Line 614B contains a signature of thesupplier Web service 606, which has a port designated as “PS” having thesupplier porttype 606B. Line 614C contains a signature for the shipperWeb services 610, which has a port designated as “PH” having the shipperporttype 610B.

[0062] Line 6141 contains the keyword service, which heralds thecommencement of the definition of a Web service or a composition of Webservices; the designator “scm_purchaser_supplier_shipper”, which denotesthe name of a composition of Web services 602, 606, and 610; and an opencurly bracket “{”, which has a companion closed curly bracket “}” todelimit the definition of the composition of Web services. Line 614Jcontains the keyword new, which defines unique names for ports andassociates these ports with particular porttypes: a new port “PC” of thepurchaser porttype 6002b; a new port “PS” of the supplier porttype 606B;a new port “PH” of the shipper porttype 610B; and an open curly bracket“{”, which has a companion closed curly bracket “}” to delimit the scopeof operations for these new ports PC, PS, and PH. Line 614K contains thekeyword parallel, which denotes that services and processes expressedbetween an open curly bracket “{” and a companion closed curly bracket“}” are to be executed in parallel.

[0063] Line 614L contains an invocation of another Web servicecomposition called “scm_Purchaser_supplier”, which takes the ports PC,PS as parameters. Digressing, the definition of the Web servicecomposition “scm_purchaser_supplier” begins at line 614D. Line 614Dcontains the keyword service indicating that a definition for Webservices or composition of Web services is about to commence; thedesignator scm_purchaser_supplier denotes the name of the Web servicecomposition; the parameter PC, which is a port 602F of the purchaserporttype 602B; a parameter PS, which is the port 610F of the supplierporttype 610B; and an an open curly bracket “{”, which has a companionclosed curly bracket “}” to delimit the definition of the Web servicecomposition scm_purchaser_supplier. Line 614E contains the keywordparallel denoting that Web services and processes defined between itsopen curly bracket “{” and closed curly bracket “}” are to be executedin parallel. Line 614F invokes the purchaser, Web service 602 with aport 602F designated as PC. Line 614G invokes the supplier Web service606 with the port 606F designated as PS. Line 614H invokes the fusingmechanism formed in accordance with this invention to fuse ports 602F(designated as PC) with ports 606F (designated as PS). Whether ports602F, 606F can be fused depends on whether the porttype 602B of thepurchaser Web service 602 is compatible with a porttype 606B of thesupplier Web service 606. More particularly, the fusing of ports 602F,606F is possible if the safety 602C of the purchaser Web service 602 canbe aligned with the safety 606C of the supplier Web service 606 so as toproduce an input guarded process. In other words, if the safeties 602C,606C can be aligned, it is programmatically safe to fuse ports 602F,606F between the purchaser Web service 602 and the supplier Web service606. A virtual contract can be created for the safe interoperabilitybetween the purchaser Web service 602 and the supplier Web service 606.This is described in detail below in connection with FIGS. 8A-8O.

[0064] Returning to the definition of the Web services compositionscm_purchaser_supplier_shipper, line 614M contains an invocation of theshipper Web service 610, which takes the port 610F designated as PH as aparameter. Line 614N contains an invocation of the fusing mechanismformed in accordance with this invention between ports 602F (PC) andport 610F (PH). If the fusing between ports cannot be accomplished dueto incompatibility between safeties or porttypes, the ports will not befused.

[0065]FIG. 6H is a dynamic visual presentation of the invocation ofoperations in a system 600 that includes the purchaser Web service 602,the supplier Web service 606, and the shipper Web service 610. Thesystem 600 commences execution with the invocation of theinitiatepurchase operation 602D and the production of the purchase order(PO). The purchaser Web service 602 then invokes the receivepo operation606D of the supplier Web service 606, provides the produced purchaseorder (PO), and the purchase order (˜PO) is then consumed by thesupplier Web service 606. The sendinvoice operation 606E is then invokedwith the production of the invoice. The supplier Web service 606 theninvokes the confirmpurchase operation 602E or the purchaser Web service602, provides the produced invoice (invoice), and the produced invoice(˜invoice) is consumed by the purchaser Web service 602. Next, thesupplier Web service 606 invokes the notifyofshipment operation 610D ofthe shipper Web service 610 and provides the advanced shipping notice(ASN). The shipper Web service 610 then provides the advanced shippingnotice (ASN) to the purchaser Web service 602 and the purchaser Webservice 602 consumes the advanced shipping notice (˜ASN). The purchaserWeb service 602 next invokes the confirmreceipt operation 610E of theshipper Web service 610 and provides the receipt of goods (goods). Inturn, the shipper Web service 610 provides the receipt of goods (goods),and the receipt of goods (˜goods) is consumed by the purchaser Webservice 602.

[0066] The foregoing discussion in FIG. 6H illustrates the invocationorder specified by the safeties 602C, 606C, 610C. However, theinteroperability among Web services 602-610 can be better appreciated bystudying the production and the consummation of messages. See FIG. 61.The system 600 commences when the purchase order (PO) is produced at theport 602F of the purchaser Web service 602 and sent to the port 606F ofthe supplier Web service 606, where the purchase order (PO) is consumed.The production of the purchase order (PO) is represented by thedesignator PO without the tilde “˜” in the parameter list of theinitiatepurchase operation 602D. The consummation of the purchase order(PO) is represented by the receivepo operation 606D with the parameter˜PO. A first process broadly represented by the initiatepurchaseoperation 602D becomes inactive (due to the safety 602C) because theport 602F has sent the purchase order (PO) but has not received theadvanced shipping notice (˜ASN). A second process broadly represented bythe receivepo operation 606D continues to a third process broadlyrepresented by the sendinvoice operation 606E (due to the safety 606C)because the port 606F has received the purchase order (˜PO). With thethird process being active, the invoice is produced at the port 606F andis sent to the port 602F of the purchaser Web service 602 where theinvoice is consumed. The safety 606C is now satisfied. The production ofthe invoice is represented by the sendinvoice operation 606E and theconsummation of the invoice is represented by the confirmpurchaseoperations 602E. A fourth process broadly represented by theconfirmpurchase operation 602E becomes inactive (due to the safety 602C)because the port 602F has not received the advanced shipping notice(˜ASN). Mini communication occurs between the supplier Web service 606and the shipper Web service 602 once the supplier Web service 606 hasreceived the purchase order (PO) at the port 606F. The advanced shippingnotice (ASN) is produced by the shipper Web services 610 at the port610F and is sent to the port 602F of the purchaser Web service 602 whereit is consumed. A fifth process broadly represented by thenotifyofshipment operation 610D continues on to a sixth process (due tothe safety 610C) broadly represented by the confirmreceipt operation610E because the port 610F has sent the advanced shipping notice (ASN),but the sixth process becomes inactive because the port 610F has notreceived the receipt of goods (˜goods). The first process broadlyrepresented by the initiatepurchase operation 602D becomes active andcontinues to the the fourth process (due to the safety 602C) broadlyrepresented by the confirmpurchase operation 602E because the port 602Fhas received the advanced shipping notice (˜ASN). The production of theadvanced shipping notice (ASN) is represented by the notifyofshipmentoperation 602D and the consummation of the advanced shipping notice(ASN) is represented by the initiatepurchase operation 602D. The fourthprocess broadly represented by the confirmpurchase operation 602Ebecomes active (due to the safety 602C) because the port 602F hasreceived the advanced shipping notice (˜ASN). With the activation of thefourth process, the receipt of goods (goods) is produced at the port602F of the purchaser Web service 602 and is sent to the port 61 OF ofthe shipper Web service 610 where it is consumed. The production of thereceipt of goods (goods) is represented by the confirmpurchase operation602E and the consummation of the receipt of goods (goods) is representedby the confirmreceipt operation 610E. The safety 602C is satisfied withthe production of the receipt of goods (goods). The sixth processbroadly represented by the confirmreceipt operation 610E becomes activebecause the port 610F has received the receipt of goods (˜goods) and thesafety 610C is then satisfied. The hereinabove discussion shows theinherent synchronization (activity and inactivity) of messages andoperations when their processing nuances are expressed using safetiesformed in accordance with this invention.

[0067] The model syntax 702 for porttypes is illustrated in FIG. 7A.Various elements of the model syntax 702 are similar to elements of thehuman-readable syntax 400 (the safety syntactical category described onlines 400C-400P). The letter S 702A denotes a named collection ofsafeties to be defined by various elements of the model syntax 702. Thesymbol “0” 702B denotes an inactive or a stop safety. The phrase “M.S”702C denotes a sequence safety, where the letter M denotes a messagetype 702I, which is followed by another safety 702A. Phrases “S₀+S₁”702D and “S₀ & S₁” 702E denote a choice to be made between the executionof the safety S₀ or the safety S₁. The phrase “S₀|S₁” 702F denotesparallel execution of safeties S₀ and S₁. The phrase “rec(K).S” 702Gdenotes a recursion of a name K 702J in the safety S. The phrase “K”702H denotes that the safety 702A can be given a name.

[0068]FIG. 7B illustrates a system 700 showing the interoperabilitybetween a first Web service 706 and a second Web service 710, the firstWeb service 706 having a safety S1 706A; a message1 operation 706B; amessage2 operation 706C; and a port 706D. The second Web service 710includes a safety S2 710A; a message3 operation 710B; a message4operation 710C; and a port 710D. The first Web service 706 and thesecond Web service 710 are shown to be fused by the fuse line 703.

[0069] FIGS. 8A-8O illustrate a method 800 for forming interoperabilityamong Web services, such as the first Web service 706 and the second Webservice 710. For clarity purposes, the following description of themethod 800 makes references to various elements illustrated inconnection with the model syntax 702 and the system 700 shown in FIGS.7A-7B. From a start block, the method 800 proceeds to a set of methodsteps 802, defined between a continuation terminal (“terminal A”) and anexit terminal (“terminal B”). The set of method steps 802 describes thecreation of Web service specifications that correspond to Web serviceprograms for first and second Web services 706, 710.

[0070] From terminal A (FIG. 8B), the method 800 proceeds to a block 808where a developer creates abstract definitions for a specification ofthe first Web service 706. Abstract definitions of a specificationinclude definitions of data types, messages, and porttypes. Next, thedeveloper creates concrete descriptions for the specification. See block810. Concrete descriptions include bindings (not to be confused with thebinding mechanism formed in accordance with the invention and describedbelow), which are where protocols, serialization, and encoding of datatransmission are specified. The concrete descriptions include serviceelements, which specify port addresses of each binding. The developerthen creates a safety S1 706A governing the invocation of operations,such as the message1 operation 706B and the message2 operation 706C, forthe specification of the first Web service 706. See block 812. Thedeveloper then preferably places the safety S1 706A (hereinafter “S1”)into the definition of the porttype for the port 606D. See block 814.Steps 808-814 can be repeated to create a specification for the secondWeb service 710 including a safety S2 710A (hereinafter “S2”). Next, themethod 800 proceeds to the exit terminal B.

[0071] From the exit terminal B (FIG. 8A), the method 800 proceeds to aset of method steps 804, defined between a continuation terminal(“terminal C”) and an exit terminal (“terminal D”). The set of methodsteps 804 describe the discovery of the second Web service 710 by thefirst Web service 706 and the verification of the ability of the secondWeb service 710 to safely interact with the first Web service 706.

[0072] From terminal C (FIG. 8C) the method 800 proceeds to a block 816where the first Web service 706 discovers a porttype of the port 710Dusing the specification of the second Web service 710 via a suitablediscovery service. One suitable discovery service includes a UDDIservice, but others are possible. The first Web service 706 then selectsa porttype of the port 706D, which is to be fused with the port 710D,from the specification of the first Web service 706. See block 818. Thefirst Web service 706 then extracts the safety S1 of the porttype of theport 706D and the safety S2 of the porttype of the port 710D. See block820. Next, the process 800 enters another continuation terminal(“terminal C18”). From terminal C18, the process 800 enters block 822where the first Web service 706 checks the interoperability betweenports 706D, 710D by attempting to place safeties S1, S2 into a bindingrelationship (S1:=:S2). At decision block 824, the first Web service 706checks whether the safety S1 is of the form “0”, which denotesinactivity or the stop safety. If the answer is YES to the test atdecision block 824, the method 800 proceeds to another continuationterminal (“terminal C1”). Otherwise, if the answer is NO, the method 800proceeds to another terminal (“terminal C2”).

[0073] From terminal C1 (FIG. 8D), the method 800 proceeds to anotherdecision block 826 where the first Web service 706 determines whetherthe safety S2 is of the form “S” 702A. If the answer is NO, anothercontinuation terminal (“terminal C19”) is entered. Otherwise, if theanswer is YES to the test at decision block 826, the bindingrelationship between the safety S1 and the safety S2 (0:=:S) is equatedto S2. See block 828. From here, the method 800 proceeds to anothercontinuation terminal (“terminal C20”).

[0074] From terminal C2 (FIG. 8D), the method 800 proceeds to anotherdecision block 830 where the first Web service 706 determines whetherthe safety S1 is of the form “M.S” 702C. If the answer is YES, anothercontinuation terminal (“terminal C3”) is entered. Otherwise, if theanswer is NO, the method 800 proceeds to another continuation terminal(“terminal C4”).

[0075] From terminal C3 (FIG. 8E) the method 800 proceeds to anotherdecision block 832 where the first Web service 706 determines whetherthe safety S2 is of the form “S₀|S₁” 706F, which denotes the parallelsafety. If the answer is NO, the process 800 enters the terminal C19.Otherwise, if the answer is YES to the test at decision block 832, block834 is entered where the safety S1 bound with the safety S2 (M.S:=S₀|S₁)is equated to two choices (S:=:S₀/M) & (S:=:S₁/M). One of the twochoices is then selected. See block 836. Next, the method 800 enterscontinuation terminal 18 to loop back to block 822 and the above stepsare repeated.

[0076] From terminal C4 (FIG. 8E) the method 800 proceeds to anotherdecision block 838 where the first Web service 706 determines whetherthe safety S1 is of the form “S₀+S₁”, which denotes a choice safety702D. If the answer is YES, another continuation terminal (“terminalC5”) is entered. Otherwise, the method 800 proceeds to anothercontinuation terminal (“terminal C6”).

[0077] From terminal C5 (FIG. 8F) the method 800 proceeds to anotherdecision block 840 where the first Web service 706 determines whetherthe safety S2 is of the form “S” 702A. If the answer is NO, continuationterminal C19 is entered by the method 800. Otherwise, if the answer isYES, the safety S1 bound with the safety S2 ((S₀+S₁):=:S)) is equated totwo choices ((S₀:=:S)+(S₁:=:S)). See block 842. One of these two choicesis then selected. See block 844. Next, the method 800 enters thecontinuation terminal C18 to loop back to 822 where the above-describedsteps are repeated.

[0078] From the terminal C6 (FIG. 8F) another decision block 846 isentered by the method 800 where the first Web service 706 determineswhether the safety S1 is of form “S₀&S₁”, which is a menu safety 702E.If the answer is NO to the test at decision block 826, anothercontinuation terminal (“terminal C8”) is entered. If instead, the answeris YES, the method 800 proceeds to another continuation terminal(“terminal C7”).

[0079] From terminal C7 the method 800 proceeds to another decisionblock 846 where the first Web service 706 determines whether the safetyS2 is of the form “S” 702A. If the answer is NO, the method 800 proceedsto terminal C19. Otherwise, if the answer is YES, block 848 is enteredwhere the safety S1 bound with the safety S2 (S₀&S₁):=:S) is equated totwo choices ((S₀:=:S)&(S₁:=:S)). One of these two choices is thenselected. See block 850. The process 800 proceeds to the terminal C18 toloop back to block 822 where the above-described method steps arerepeated.

[0080] From terminal C8 the method 800 proceeds to another decisionblock 852 where the first Web service 706 determines whether the safetyS1 706A is of the form “S₀|S₁”, which denotes the parallel safety 702F.If the answer is NO, the method 800 proceeds to another continuationterminal (“terminal C11”). Otherwise, if the answer is YES, anothercontinuation terminal (“terminal C9”) is entered.

[0081] From terminal C9 the method 800 proceeds to another decisionblock 854 where the first Web service 706 determines whether the safetyS2 of the second Web service 710 is of the form “S₂|S₃”, which is in theform of the parallel safety 702F. If the answer is NO to the test atdecision block 854, the method 800 proceeds to terminal C19. Otherwise,if the answer is YES, block 856 is entered by the method 800. At thisblock, the safety S1 bound with the safety S2 ((S₀|S₁):=:(S₂|S₃)) isequated to a set of four choices(S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2)). Each of thefour choices can be placed in a form S_(i,m,n,j). See block 858. Foreach choice of the four choices, a test is made to determine whether therelationship (S_(i):=:(S_(m)|S_(n))):=:S_(j) is defined for a particularchoice. See decision block 860. If the answer to the test at decisionblock 860 is YES, the particular choice is then equated to therelationship (S_(i):=:(S_(m)|S_(n))):=:S_(j). See block 862. Next, themethod 800 proceeds to another continuation terminal (“terminal C10”).If instead the answer is NO, block 864 is entered where the particularchoice is equated to the relationship (S_(i):=:(S_(m)|S_(n)))|S_(j). Themethod 800 then also proceeds to the terminal C10.

[0082] From terminal C10 (FIG. 8I), the method 800 proceeds to block 866where one of the four choices(S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2)) is selected. Theprocess 800 then proceeds to terminal C18 to loop back to block 822where the above-described method steps are repeated.

[0083] From the terminal C11 (FIG. 8I) the method 800 proceeds toanother decision block 868 where the first Web service 706 determineswhether the safety S1 is of form rec(K).S₀, which denotes a recursionsafety 702G. If the answer is NO to the test at decision block 868,another continuation terminal (“terminal C12”) is entered. Otherwise, ifthe answer is YES, another decision block 870 is entered where the firstWeb service 706 checks whether the safety S2 is of the form “S” 702A. Ifthe answer is NO to the test at decision block 870, terminal C19 isentered by the method 800. If instead, the answer is YES, the method 800proceeds to block 872 where the safety S1 bound with the safety S2(rec(K).S₀:=:S) is equated to (S₀{rec(K).S₀/K}:=:S). The syntacticalphrase S₀{rec(K).S₀/K} means that wherever in the safety S₀ there is amention of K, which is a name as defined by the model syntax 702, K isreplaced by rec(K).S₀. Consider the following example: if the phrase“S₀{rec(K).S₀/K}” were to be applied to the safety sentence“S₀=open.close.S₀”, the result would be as follows:“S₀=open.close.rec(S₀).open.close.S₀”. Thus, the “S₀” in the example isthe K in the recursion safety “rec(K)”. Next, the method 800 proceeds toterminal C18 to loop back to block 822 where the above-described methodsteps are repeated. If the answer to the test at decision block 870 isNO, the method 800 proceeds to terminal C19.

[0084] From terminal C12 (FIG. 8J), the method 800 proceeds to anotherdecision block 874 where the first Web service 706 checks whether thesafety S1 is of the form “S” 702A. If the answer is NO, the method 800proceeds to terminal C19. Otherwise, if the answer is YES, anotherdecision block 876 is entered. At this decision block, the first Webservice 706 determines whether the safety S2 is of the form “0/S₀”. Ifthe answer is NO, the method 800 proceeds to another continuationterminal (“terminal C13”). Otherwise, if the answer to the test atdecision block 876 is YES, the safety S1 bound with the safety S2(S:=:0/S₀) is undefined. See block 878. The method 800 then proceeds toterminal C20.

[0085] From terminal C13 (FIG. 8K), the method 800 proceeds to anotherdecision block 880 where the first Web service 706 verifies whether thesafety S2 is of the form “M₀.S/M₁”. If the answer is NO, the method 800proceeds to another continuation terminal (“terminal C14”). If theanswer is YES, the first Web service 706 determines whether a matchfunction, which takes M₀, M₁ as arguments, is defined. See block 882. Asimple implementation of the match function includes a return of a TRUEBoolean result if M₀ is the complement of M₁. Otherwise, the matchfunction would return a FALSE Boolean result. If the answer to the testat decision block 882 is NO, the safety S1 bound with the safety S2(S:=:M₀.S/M₁) is undefined. See block 886. The method 800 then proceedsto terminal C20. If the answer to the test at decision block 882 is YES,the safety S2 is equated to “cut (M₀, M₁).S”, where cut is a functionthat takes M₀, M₁ as arguments. One preferable implementation of the cutfunction is shown in Appendix A (the “comm” rule under Section 3.2,where M₀, M₁ can be substituted for Q₀, Q₁). Next, the process 800proceeds to terminal C18 to loop back to block 822 where theabove-described method steps are repeated.

[0086] From terminal C14, the method 800 proceeds to another decisionblock 888 where the first Web service 706 determines whether the safetyS2 is of the form “(S₀+S₁)/M”. If the answer is YES, the safety S2 isequated to two choices (S₀/M)+(S₁/M). See block 890. One of these twochoices is selected. See block 892. Next, the method 800 proceeds toterminal C18 to loop back to block 822 where the above-described methodsteps are repeated. If the answer to the test at decision block 888 isNO, another decision block 894 is entered. At this decision block, thefirst Web service 706 verifies whether the safety S2 is of the form(S₀&S₁)/M. If the answer is NO, the method 800 proceeds to anothercontinuation terminal (“terminal C16”). Otherwise, the answer is YES tothe test at decision block 894, the safety S2 is equated to two choices,(S₀/M)&(S₁/M). The method 800 then proceeds to another continuationterminal (“terminal C15”).

[0087] From terminal C15 (FIG. 8M) the process 800 proceeds to block 898where one of the two choices (S₀/M)&(S₁/M) is selected. The method 800then proceeds to terminal C18 to loop back to block 822 where theabove-described method steps are repeated. From terminal C16 (FIG. 8M)the method 800 proceeds to another decision block 899 where the firstWeb service 706 checks the safety S2 to determine whether it has theform (S₀|S₁)/M. If the answer is NO, the method 800 proceeds to anothercontinuation terminal (“terminal C17”). Otherwise, the answer is YES,and the safety S2 is equated to two choices (S₀/M)&(S₁/M). See block897. Next, the process 800 proceeds to block 895 where one of the twochoices is then selected. Then, the method 800 proceeds to the terminalC18 to loop back to block 822 where the above-described method steps arerepeated.

[0088] From terminal C17 (FIG. 8N) the method 800 proceeds to anotherdecision block 893 where the first Web service 706 determines whetherthe safety S2 is of the form rec(K).S/M. If the answer is YES, thesafety S2 is equated to (rec(K).(S/M)). See block 891. The method 800then proceeds to terminal C18 to loop back to block 822 where theabove-described method steps are repeated. Otherwise, the answer to thetest at decision block 893 is NO, and terminal C19 is entered.

[0089] From terminal C19 (FIG. 8N) the first Web service 706 determinesthat a syntax error has occurred because either the safety S1 or thesafety S2 does not comply with the model syntax 702. See block 889.Fusing between ports 706D, 710D is not possible because safeties S1, S2are not in a form that can be computed. The method 800 then terminatesprocessing. From terminal C20 (FIG. 8N), the method 800 proceeds toblock 887 where a temporary safety S3 is set to equate to the result ofthe binding relationship between the safeties S1 and the safety(S₃=S₁:=:S₂). The method 800 then enters exit terminal D.

[0090] From exit terminal D, the method 800 proceeds to a set of methodsteps 806, defined between a continuation terminal (“terminal E”) and anexit terminal (“terminal F”). The set of method steps 806 creates avirtual contract, which is a binding agreement, between the first Webservice 706 and the second Web service 710 if the safeties S1 and thesafety S2 can be aligned in a suitable manner that allows for safeinteroperability between the first Web service 706 and the second Webservice 710.

[0091] From terminal E (FIG. 8O) the method 800 proceeds to anotherdecision block 885 where the first Web service 706 determines whetherthe safety S3 (which is the result of the binding relationship betweenthe safety S1 and the safety S2) is equal to zero. If the answer to thetest at decision block 885 is YES, the port 706D of the first Webservice 706 can be fused with the port 710D of the second Web service710. See block 881. When two ports can be fused in this way, theinteroperability between the first Web service 706 and the second Webservice 710 is safe. The term “safe” means that there exists an inputguarded process; that every output has met an input; or that there is nodeadlock because the input of either the first Web service 706 or thesecond Web service 710 is always available to receive messages toprocess them. Once ports 706D, 710D are fused, the second Web service710 can commence communicating with the first Web service 706 to provideor to obtain desired services. See block 879. The method 800 thenproceeds to exit terminal F where it terminates processing.

[0092] If the answer to the test at decision block 885 is NO, anotherdecision block 883 is entered where the first Web service 706 determineswhether it can tolerate a certain degree of unsafe fusing of ports 706D,710D. If the answer is YES, method steps 881, 879 are repeated.Otherwise, the answer to the test at decision block 883 is NO; ports706D, 710D are not fused; and the method 800 proceeds to exit terminal Fwhere it terminates processing.

[0093] While the preferred embodiment of the invention has beenillustrated and described, it will be appreciated that various changescan be made therein without departing from the spirit and scope of theinvention.

The embodiments of the invention in which an exclusive property orprivilege is claimed are defined as follows:
 1. A networked system forallowing Web services to communicate, comprising: a first Web servicefor offering computing services, the first Web service including a firstport for transmitting and receiving messages, the first port including afirst porttype; and a second Web service that desires the computingservices offered by the first Web service, the second Web serviceincluding a second port for transmitting and receiving messages, thesecond port including a second porttype, the second port being fusablewith the first port for safe access to the services offered by the firstWeb service if the second porttype is compatible with the firstporttype.
 2. The networked system of claim 1, wherein the first Webservice includes a third port for transmitting messages, and the secondWeb service provides a fourth port for receiving messages from the thirdport.
 3. The networked system of claim 2, wherein the fourth port islocated on a third Web service, the fourth port being provided to thesecond Web service by the third Web service.
 4. The networked system ofclaim 1, wherein the first Web service is executed on a first computingdevice.
 5. The networked system of claim 2, wherein the second Webservice is executed on a second computing device.
 6. A networked systemfor allowing Web services to communicate, comprising: a first Webservice offering a first set of services, the first Web serviceincluding a first safety that programmatically expresses safe access tothe first set of services; and a second Web service offering a secondset of services, the second Web service including a second safety thatprogrammatically expresses safe access to the second set of services,the second Web service accessing the first set of services and the firstWeb service accessing the second set of services if the second safety isable to programmatically align with the first safety.
 7. The networkedsystem of claim 6, wherein the first set of services of the first Webservice are accessible via a first set of operations, the first safetyprogrammatically specifying allowable invocation permutations of thefirst set of operations.
 8. The networked system of claim 7, wherein thesecond set of services of the second Web service are accessible via asecond set of operations, the second safety programmatically specifyingallowable invocation permutations of the second set of operations. 9.The networked system of claim 8, wherein the first Web service includesa first porttype, the first porttype including the first set ofoperations and the first safety.
 10. The networked system of claim 9,wherein the second Web service includes a second porttype, the secondporttype including the second set of operations and the second safety.11. A networked system for allowing Web services to communicate,comprising: a first Web service offering services, the first Web serviceincluding a safety that programmatically describes an order in which toaccess the offered services; and a second Web service that desires heservices offered by the first Web service, the second Web serviceaccepting the safety of the first Web service to form a virtual contractwith the first Web service so that the second Web service can access theoffered services.
 12. The networked system of claim 11, wherein thefirst Web service includes a first porttype and the second Web serviceincludes a second porttype, wherein the virtual contract is formed whenthe first porttype is compatible with the second porttype.
 13. Thenetworked system of claim 11, wherein the second Web service includesanother safety, wherein the virtual contract is formed when the safetiesare acceptable to both the first Web service and the second Web service.14. The networked system of claim 11, wherein the first Web serviceincludes a first port and the second Web service includes a second port,wherein the first port and the second port is fused when the virtualcontract is formed.
 15. The networked system of claim 11, wherein thefirst Web service programmatically joins the second Web service when thevirtual contract is created to form a composition Web service thatcomprises both the first Web service and the second Web service.
 16. Acomputer-readable medium having a customizable, tag-based data structurestored thereon for use by a Web service to evaluate safeinteroperability with another Web service, the data structurecomprising: a porttype tag that is indicative of operations capable ofbeing invoked by Web services; and a safety tag that is indicative of asafety that programmatically specifies an order by which Web servicesinvoke the operations.
 17. The computer-readable medium of claim 16,wherein the safety tag is nested within the porttype tag.
 18. Thecomputer-readable medium of claim 17, wherein nesting within theporttype tag are one or more signature tags that are indicative ofsignatures of the operations.
 19. The computer-readable medium of claim17, wherein nesting within the safety tag is a stop safety tag that isindicative of inactivity or termination of the safety.
 20. Thecomputer-readable medium of claim 17, wherein nesting within the safetytag is a choice safety tag that is indicative of a choice between twosafeties.
 21. The computer-readable medium of claim 17, wherein nestingwithin the safety tag is a menu safety tag that is indicative of achoice between two safeties.
 22. The computer-readable medium of claim17, wherein nesting within the safety tag is a parallel safety tag thatis indicative of parallel execution of two safeties.
 23. Thecomputer-readable medium of claim 17, wherein nesting within the safetytag is a recursion safety tag that is indicative of a recursion of thesafety.
 24. The computer-readable medium of claim 17, wherein nestingwithin the safety tag is a reference safety tag that is indicative of aname for the safety.
 25. A computer-implemented method for creating aspecification for a Web service that corresponds to a program of the Webservice, the method comprising: creating a set of operations that arecapable of being invoked by Web services; and creating a safety thatspecifies the permissible invocation permutations of the set ofoperations.
 26. The method of claim 25, wherein the method furthercomprising creating a porttype and placing the set of operations and thesafety in the porttype.
 27. The method of claim 26, wherein the methodfurther comprising creating abstract definitions of the Web service andplacing the porttype into the abstract definitions of the Web service.28. The method of claim 27, wherein the method further comprisingcreating concrete descriptions for the Web service.
 29. Acomputer-readable medium having computer-executable instructions forperforming a method of creating a specification for a Web service thatcorresponds to a program of the Web service, the method comprising:creating a set of operations that are capable of being invoked by Webservices; and creating a safety that specifies the permissibleinvocation permutations of the set of operations.
 30. Thecomputer-readable medium of claim 29, wherein the method furthercomprising creating a porttype and placing the set of operations and thesafety in the porttype.
 31. The computer-readable medium of claim 30,wherein the method further comprising creating abstract definitions ofthe Web service and placing the porttype into the abstract definitionsof the Web service.
 32. The computer-readable medium of claim 31,wherein the method further comprising creating concrete descriptions forthe Web service.
 33. A computer-implemented method for checking thecompatibility of a first porttype of a first Web service and a secondporttype of the second Web service, the method comprising: extracting afirst safety (S1) from the first porttype of the first Web service and asecond safety (S2) from the second porttype of the second Web service;and testing the compatibility of the first safety with the second safetyby binding the first safety with the second safety (S1:=:S2) todetermine whether the result of the binding is an input-guarded process.34. The method of claim 33, wherein the first Web service includes afirst port of the first porttype and the second Web service includes asecond port of the second porttype, the first port being fusable withthe second port if the result of the binding is an input guardedprocess.
 35. The method of claim 33, wherein the first Web serviceincludes a first port of the first porttype and the second Web serviceincludes a second port of the second porttype, the first port beingfusable with the second port if the result of the binding is not aninput-guarded process and both the first Web service and the second Webservice tolerate the fusing of the first port and the second port. 36.The method of claim 33, wherein if the first safety is a stop safety (0)and the second safety is of the form (S), the result of the binding isthe second safety.
 37. The method of claim 33, wherein if the firstsafety is a sequence safety (M.S) and the second safety is a parallelsafety (S₀|S₁), the result of the binding is a menu safety((S:=:S₀/M)&(S:=:S₁/M)).
 38. The method of claim 33, wherein if thefirst safety is a choice safety (S₀+S₁) and the second safety is of theform (S), the result of the binding is a choice safety((S₀:=:S)+(S₁:=:S)).
 39. The method of claim 33, wherein if the firstsafety is a menu safety (S₀&S₁) and the second safety is of the form(S), the result of the binding is a menu safety ((S₀:=:S)&(S₁:=:S)). 40.The method of claim 33, wherein if the first safety is a parallel safety(S₀|S₁) and the second safety is another parallel safety (S₂|S₃), theresult of the binding is a menu safety((S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2))).
 41. Themethod of claim 40, wherein each choice in the menu safety((S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2))) can be placedin a form (S_(i,m,n,j)), wherein if a relationship((S_(i):=:(S_(m)|S_(n))):=:S_(j)) is defined for a particular choice,the result of the binding is the relationship((S_(i):=:(S_(m)|S_(n))):=:S_(j)) or otherwise the result of the bindingis another relationship ((S_(i):=:(S_(m)|S_(n)))|S_(j)).
 42. The methodof claim 33, wherein if the first safety is a recursion safety(rec(K).S₀) and the second safety is of the form (S), the result of thebinding is a relationship (S₀{rec(K).S₀/K}:=:S).
 43. The method of claim33, wherein if the first safety is of the form (S) and the second safetyis of the form (0/S₀), the result of the binding is undefined.
 44. Themethod of claim 33, wherein if the first safety is of the form (S) andthe second safety is of the form (M₀.S/M₁) and a match function(match(M₀, M₁)) is defined, the result of the binding is equated to acut function (cut(M₀, M₁)).
 45. The method of claim 33, wherein if thefirst safety is of the form (S) and the second safety is of the form(M₀.S/M₁) and a match function (match(M₀, M₁)) is not defined, theresult of the binding is undefined.
 46. The method of claim 33, whereinif the first safety is of the form (S) and the second safety is of theform ((S₀+S₁)/M), the result of the binding is equated to a choicesafety ((S₀/M)+(S₁/M)).
 47. The method of claim 33, wherein if the firstsafety is of the form (S) and the second safety is of the form((S₀&S₁)/M), the result of the binding is equated to a menu safety((S₀/M)&(S₁/M)).
 48. The method of claim 33, wherein if the first safetyis of the form (S) and the second safety is of the form ((S₀|S₁)/M), theresult of the binding is equated to a menu safety ((S₀/M)&(S₁/M)). 49.The method of claim 33, wherein if the first safety is of the form (S)and the second safety is of the form (rec(K).S/M), the result of thebinding is equated to a recursion safety (rec(K).(S/M)).
 50. Acomputer-readable medium having computer-executable instructions forperforming a method for checking the compatibility of a first porttypeof a first Web service and a second porttype of the second Web service,the method comprising: extracting a first safety (S1) from the firstporttype of the first Web service and a second safety (S2) from thesecond porttype of the second Web service; and testing the compatibilityof the first safety with the second safety by binding the first safetywith the second safety (S1:=:S2) to determine whether the result of thebinding is an input-guarded process.
 51. The computer-readable medium ofclaim 50, wherein the first Web service includes a first port of thefirst porttype and the second Web service includes a second port of thesecond porttype, the first port being fusable with the second port ifthe result of the binding is an input guarded process.
 52. Thecomputer-readable medium of claim 50, wherein the first Web serviceincludes a first port of the first porttype and the second Web serviceincludes a second port of the second porttype, the first port beingfusable with the second port if the result of the binding is not aninput-guarded process and both the first Web service and the second Webservice tolerate the fusing of the first port and the second port. 53.The computer-readable medium of claim 50, wherein if the first safety isa stop safety (0) and the second safety is of the form (S), the resultof the binding is the second safety.
 54. The computer-readable medium ofclaim 50, wherein if the first safety is a sequence safety (M.S) and thesecond safety is a parallel safety (S₀|S₁), the result of the binding isa menu safety ((S:=:S₀/M)&(S:=:S₁/M)).
 55. The computer-readable mediumof claim 50, wherein if the first safety is a choice safety (S₀+S₁) andthe second safety is of the form (S), the result of the binding is achoice safety ((S₀:=:S)+(S₁:=:S)).
 56. The computer-readable medium ofclaim 50, wherein if the first safety is a menu safety (S₀&S₁) and thesecond safety is of the form (S), the result of the binding is a menusafety ((S₀:=:S)&(S₁:=:S)).
 57. The computer-readable medium of claim50, wherein if the first safety is a parallel safety (S₀|S₁) and thesecond safety is another parallel safety (S₂|S₃), the result of thebinding is a menu safety((S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2))).
 58. Thecomputer-readable medium of claim 57, wherein each choice in the menusafety ((S_(0,2,3,1))&(S_(1,2,3,0))&(S_(2,0,1,3))&(S_(3,0,1,2))) can beplaced in a form (S_(i,m,n,j)), wherein if a relationship((S_(i):=:(S_(m)|S_(n))):=:S_(j)) is defined for a particular choice,the result of the binding is the relationship((S_(i):=:(S_(m)|S_(n))):=:S_(j)) or otherwise the result of the bindingis another relationship ((S_(i):=:(S_(m)|S_(n)))|S_(j)).
 59. Thecomputer-readable medium of claim 50, wherein if the first safety is arecursion safety (rec(K).S₀) and the second safety is of the form (S),the result of the binding is a relationship (S₀{rec(K).S₀/K}:=:S). 60.The computer-readable medium of claim 50, wherein if the first safety isof the form (S) and the second safety is of the form (0/S₀), the resultof the binding is undefined.
 61. The computer-readable medium of claim50, wherein if the first safety is of the form (S) and the second safetyis of the form (M₀.S/M₁) and a match function (match(M₀, M₁)) isdefined, the result of the binding is equated to a cut function (cut(M₀,M₁)).
 62. The computer-readable medium of claim 50, wherein if the firstsafety is of the form (S) and the second safety is of the form (M₀.S/M₁)and a match function (match(M₀, M₁)) is not defined, the result of thebinding is undefined.
 63. The computer-readable medium of claim 50,wherein if the first safety is of the form (S) and the second safety isof the form ((S₀+S₁)/M), the result of the binding is equated to achoice safety ((S₀/M)+(S₁/M)).
 64. The computer-readable medium of claim50, wherein if the first safety is of the form (S) and the second safetyis of the form ((S₀&S₁)/M), the result of the binding is equated to amenu safety ((S₀/M)&(S₁/M)).
 65. The computer-readable medium of claim50, wherein if the first safety is of the form (S) and the second safetyis of the form ((S₀|S₁)/M), the result of the binding is equated to amenu safety ((S₀/M)&(S₁/M)).
 66. The computer-readable medium of claim50, wherein if the first safety is of the form (S) and the second safetyis of the form (rec(K).S/M), the result of the binding is equated to arecursion safety (rec(K).(S/M)).